Microsoft Lync Server 2010 : Planning for Deploying External Services - Edge Server Considerations

The first step in planning for Edge services is to determine what the business requirements are, which features need to be deployed, and what kind of topology to use. For instance, a small business that wants to communicate with public IM networks might deploy a single server running the Access Edge Server role, whereas a larger business that wants to replace a hosted virtual conferencing solution might deploy multiple, load-balanced Edge Servers with full support for A/V conferencing. This section discusses the different forms of remote access and considerations for each feature.

Remote Access

When planning for Edge services it is important to realize that the remote access features touch many different facets of Lync Server. The remote access features allows endpoints to sign in to Lync Server across the Internet. Keep in mind that to support any of the web conferencing or A/V features across the Internet, remote access must be configured.

Remote access policies can be used to control which users, groups, or locations are permitted to sign in remotely. Identify what user sets should be configured for remote access, and then create access policies to assign to these groups.

Anonymous Access

Whether an organization supports anonymous access to Lync Server is a decision the business must make when considering an Edge Server deployment. Allowing anonymous access provides the ability for internal users to invite participants from outside to the organization to web or A/V conferencing sessions. This ability can often replace hosted or subscription-based conferencing services for most users, providing immediate cost savings. For extremely large conferences, it might still make sense to use a hosted service, but the majority of ad-hoc or smaller conferences can easily be handled by Lync Server.

Another option is that only specific users, groups, or locations can be given the ability to communicate with anonymous users through the use of conferencing policies. This allows administrators the flexibility of allowing all authenticated users to use web conferencing, but maybe only a select few are allowed to host conferences with anonymous participants.

Federation

When deploying Edge Servers, make a decision about whether users are allowed to federate with other organizations that run Lync Server. Making a decision about whether federation is enabled is the first step, but the second is to determine what type of federation is allowed.

In Lync Server, organizations can use open federation, where federation to all domains is allowed, or direct federation, where users might federate only with organizations explicitly approved by an administrator. There are advantages to both approaches, but there is an increasing trend to allowing open federation because of how easily it extends the reach of a Lync Server deployment.

A good analogy here when considering whether to use open or closed federation is to think of federation in terms of e-mail. Imagine if e-mail operated like direct federation where users in different domains cannot send mail to each other without an administrator on both sides first approving the partner domain. If that were the case, e-mail probably would not have become the universal communication modality that it is today. Instead, any user can generally send mail to any domain without administrators making server configuration changes. Open federation is the Lync Server equivalent of that ability; users have full access to presence, instant messaging, web conferencing, and A/V conferencing with any other user across the world without any additional configuration. Federation has a leg up on e-mail because it allows for much richer communication methods between partners.

Direct Federation

There might be times when open federations simply are not an option because of security or policies. In those cases, it might be necessary to use direct federation and manually configure the Edge Servers to federate with only specific domains. If using closed federation, be sure to coordinate with an administrator at any partner domains to check whether they also use closed federation. If so, the administrator for the partner also needs to make a change to the system to allow the federation so it works in both directions. These extra steps are another reason open federation is an attractive option.

There is no dependency on both sides of a federated relationship to use the same type of federation. One organization might use direct federation and allow only one specific partner, but that partner might have open federation enabled, allowing users to communicate with any federated domain.

Either way, upfront planning is necessary to determine whether to allow federation and what type of federation will be enabled. After making that decision, identify any domains that should be specifically allowed or blocked.

The next step in deploying federation is to identify the users who should be allowed to use federation. Even if federation is provisioned for an Access Edge Server configuration, the ability to use federation can still be controlled on a global, site, or per-user basis with remote access policies.

Public IM Connectivity

Lync Server Public IM Connectivity (PIC) enables users to communicate with public instant messaging (IM) networks such as MSN, AOL, and Yahoo!. It operates in a similar fashion to federation in that it uses the same ports and topology, but has a slightly different set of steps to configure. The main difference is that Public IM Connectivity must be configured through the organization’s licensing site with Microsoft. The public IM providers do not use the SRV record for open federation and instead require these manual steps to provision the initial connectivity.

Administrators can choose to allow only specific SIP domains to communicate with the public IM providers. Each SIP domain supported for Public IM Connectivity must be provisioned through the licensing site. After provisioning the Public IM Connectivity, it can take up to 30 days before each provider activates the change, and because each provider is independent, they can come online at different times.

Public IM connections have a more limited feature set than federation does. The Public IM providers do not support any kind of multiparty IM or conferencing, so all conversations are limited to two participants. Public IM providers also do not support any kind of web conferencing or A/V features, even on a two-party basis. The only exceptions to this are the MSN and Windows Live services that actually do allow two-party A/V conversations with Lync Server users.

Capacity Planning

Plan for enough Edge Servers to meet capacity requirements of the environment. An Edge Server that meets the recommended specifications is capable of supporting up to 15,000 simultaneous IM and presence users. For redundancy, or to support more than 15,000 external users, and then simply use additional Edge Servers in the pool.

Edge Placement

Edge Server placement is critical in a deployment to optimize media paths. The SIP signaling used for presence and IM is more tolerant of slight delays, but web conferencing and A/V traffic are sensitive to latency, so it is important to properly plan Edge Server placement.

For example, consider a small deployment for Company ABC, as shown in Figure 1 where a single Front-End Server in San Francisco exists. In this deployment, only a single Edge Server is necessary to support all the remote features. Media paths are all local to San Francisco.

Imagine Company ABC expands with a new office in London with a WAN link back to San Francisco and adds a new Front-End pool for the London users. The London users have been assigned policies that allow remote access, but no conferencing or A/V traffic. In this case, the single Edge Server in San Francisco can still support the London Front-End pool. The SIP signaling enters the San Francisco Edge Server, uses the San Francisco Front-End as next hop, and then communicates with the London Front-End Server. London users have full remote access presence and IM capabilities.

Now consider that Company ABC wants to allow London users to conduct conferences with A/V remotely. There is the potential for users in London who must use the San Francisco A/V Edge Server to relay media traffic. This is inefficient and can result in a poor experience for the remote London users because of the latency involved with each packet traversing to San Francisco and back. There can be a London user on the Internet trying to do an A/V call with another London user who is internal, but the media traffic flows all the way back to the San Francisco Edge Server just to reach the internal London user. Figure 2 shows how inefficient this media path can be.

The solution in this scenario is to also deploy an Edge Server in London so that users there have a local point to relay media when remote. The SIP signaling still travels through the San Francisco Access Edge Server, but media traffic is much improved. If Company ABC deploys an Edge Server in London, the traffic flow shown in Figure 27.2 changes to the traffic flow shown in Figure 3. In this case, the remote users can exchange media traffic with London users directly across the Internet.